Business applications and other computer software applications are typically shipped with a help system to explain various aspects, features and components of the application. Help systems are invoked by users of the applications when the user has a question or encounters a problem. Help systems then generate a help user interface to present information directed to the question or problem.
In many applications, the help user interface presents the user with an opportunity to select from a general index of help topics and sub-topics and thereby navigate to the desired content. Some applications provide an interface querying the user for keywords indicative of the question or problem. In either case, the user interface provides a mechanism to locate the desired content within a database or other set of previously prepared articles or content items covering various topics, sub-topics, frequently asked questions (FAQ), etc.
Some help systems are context-sensitive to facilitate an automatic presentation of relevant help content. In these cases, the help system is invoked from within the application via user selection of an element displayed in the application's user interface. The selected display element may constitute, for instance, a display window, box, or panel, or a component thereof, such as a graphical button or pull-down menu. By selecting such display elements in connection with invoking the help system, often via a keystroke (e.g., the function key F1), the user is then presented with help content related to the selected display element. In this way, the help topic index and keyword query are bypassed, and the help user interface automatically displays a targeted portion of the content available for presentation.
Despite improvements in help user interfaces, help systems typically remain limited to the presentation of static content previously prepared by or on behalf of the software developer. But updates, changes and revisions to the help content become necessary over time. In response, software developers have made help resources available on-line. In this way, the software developer can update the content from time to time as necessary.
Generally speaking, however, the use of on-line help resources has, at times, undesirably removed the user from the application environment. As a result, on-line help resources may be limited to presenting a topic index, a keyword query, or FAQ list. That is, once outside of the application environment, the help system may be unable to tailor the content based on the context of the help request. As a result, on-line resources and other help systems generally remain limited to presenting generic content not customized for the user context in which it is requested. Such generic content typically relates to standard features of the application. Any customization for a specific installation would then not be covered. In these ways, the help files shipped with a product or provided later via an on-line delivery have typically been static and incapable of adaptation to a customized application.
In fact, on-line and other help resources may become incompatible with the application environment due to customization after shipment by the original developer. Such customization may arise from a variety of secondary development sources, including development partners, system administrators, and end users. Often, the secondary developments can be extensive. As a result, applications have been shipped with the capability of providing secondary developers with the opportunity to add to and modify the help content made available to end users. Unfortunately, incompatibility problems may still arise after such changes to the help content have been made. For example, software updates subsequently released by the original developer may overwrite or otherwise corrupt the customizations to the help system that had been made by the secondary developer since the previous revision or update.